A number of tasks executing in a microcontroller may use a semaphore (see FIG. 1A) as a synchronization mechanism, to access a common location in memory, to ensure that data at that location is not changed by one task while that data is being used by another task. Use of such a semaphore ensures, for example, that a packet counter is properly incremented (or a database entry is properly accessed) by each of a number of tasks that execute concurrently or simultaneously in the microcontroller.
In using a semaphore, when one task, e.g. Task0 in FIG. 1B, is accessing a memory location, other tasks, e.g. Task1, Task2, and Task3, that also need to access that same memory location are suspended (i.e. are made to wait). While such other tasks are waiting, Task0 may be activated from sleep (e.g. Task0 may have been previously put to sleep at time t4 soon after issuance of a request for the semaphore and may be awakened only at time t8), Task0 may issue a read request on being awakened, may again be put to sleep while waiting for a response from memory (e.g. at time t9), may again be awakened on receiving the memory response (e.g. at time t10), perform a read operation, and finally release the semaphore (e.g. at time t10). Only at this point is the semaphore available for use by the next task, Task1.
Therefore, use of a semaphore effectively single threads the access to a common memory location in all of the tasks, even though a microcontroller (such as a network processor) may support multitasking. Such single threading causes the latency of each task to affect all subsequently-performed tasks. Note that in addition to latency inherent in memory, latency may be added by the presence of memory management hardware (also called “load store unit” abbreviated as LSU), as illustrated in FIG. 1C.
U.S. Pat. No. 5,790,881 granted to Nguyen on Aug. 4, 1998 entitled “Computer system including coprocessor devices simulating memory interfaces” suggests (see abstract) “coupling a coprocessor to a master device, in which the coprocessor emulates an memory interface to the master device, like that of a memory device. . . . The coprocessor is disposed to receive data written from the master device, perform a coprocessing function on that data, and respond to a read data command from the master device with processing results.”
See also U.S. Pat. No. 6,338,108 granted to Motomura on Jan. 8, 2002 entitled “Coprocessor-integrated packet-type memory LSI, packet-type memory/coprocessor bus, and control method thereof” which states (see abstract) that “[a]memory section and coprocessor sections in a coprocessor-integrated packet-type DRAM are provided with unique memory device ID and coprocessor device IDs respect-vely . . . ”